58用户行为数据仓库建设及实践
The following article is from 58技术 Author 路亚州
导语
刚刚度过了一个特殊的春节，58技术在这里给大家拜个晚年。疫情当前，请大家做好个人和家庭防护，健康饮食、规律作息、增强运动、提高免疫力。“没有一个冬天不会过去，没有一个春天不会到来”，让我们一起为武汉加油！
相信各位技术大牛都在忙碌地进行着各种技术支撑方面的工作，远程办公，学习不能中断，今天58技术给大家分享一篇文章——《58全站用户行为数据仓库建设及实践》，文章系统论述了全站行为数据仓库建设实践过程中所运用的方法论及实践经验总结，希望对大家有所帮助和启发。
背景
随着58业务体系的不断建设与发展，数据分析与应用需求越来越丰富，给数据仓库的建设工作带来了很大的挑战。
全站行为数据仓库建设过程中，我们总结的问题包括如下几点：
(1) 数据体系架构已经无法支持业务的快速迭代，数据集成的开发、维护成本高；
(2) 数据业务知识散乱，数据分析与应用成本高；
(3) 数据质量定义模糊，缺乏有效统一的数据质量监控体系；
(4) 缺失数据建设规范，数据开发、表结构定义不统一，数据任务、数据表维护成本高。
综上，全站行为数据仓库的建设，需要在现有的大数据平台基础上，借鉴互联网行业通用的维度建模方法论，构建架构合理，分层清晰，具有统一数据规范的全站行为数据仓库。
大数据领域建模综述
1. 为什么需要数据建模
数据仓库是一个面向主题的、集成的、时变的、非易失的数据集合。数据仓库中的数据需要进行有序、有结构地分类组织和存储。通过建立适合业务和基础数据存储环境的模型，可以带来以下优点：
(1) 性能：快速查询数据，减少数据的I/O吞吐；
(2) 成本：减少数据冗余，计算结果复用；
(3) 效率：改善用户的使用数据体验，提高使用数据效率；
(4) 质量：改善数据统计口径的不一致性，减少数据计算错误的可能性。
2. 典型的数据仓库建模方法论
行业内，典型的数据仓库建模方法论主要分为以下几种：
(1) ER模型——全企业的高度设计一个3NF模型，描述企业业务。
a) 高层模型：高度抽象，主要的主题以及主题间的关系
b) 中层模型：细化主题的数据项
c) 物理模型：基于性能和平台特点进行物理属性的设计，如表合并，分区设计
(2) 维度模型——为分析决策需求服务
a) 选择需要进行分析决策的业务过程；
b) 选择粒度；
c) 识别维表；
d) 选择事实。
(3) Data Vault模型——ER模型的衍生，实现数据整合。
a) Hub：企业核心业务实体；
b) Link：Hub之间的关系。Hub的代理键、装载时间、数据来源组成；
c) Satellite：Hub的详细描述内容。
(4) Anchor模型——k-v结构化模型
a) Anchors：类似Hub，只有主键；
b) Attributes：类似Satellite,规范化，全部k-v结构化；
c) Ties：描述Anchors的关系。单独用表来描述；
d) Knots：可能在多个Anchors中公用的属性的提炼。
全站行为数据仓库落地建设实践过程中，参考互联网行业内采用广泛的维度建模方法论，结合58商业自身特点，分析业务环境构造数据仓库底层数据基础，再按照实际的应用需求构造数据仓库上层数据的方式进行数据仓库的建设。
全站行为数据仓库建设实践
下图为数据仓库中全站行为数据部分数据仓库体系架构图：
图1 全站行为数据架构图
1. 全站行为数据概述
全站行为数据是指在主站数据内，一次帖子检索过程，对应的用户浏览、点击、交互行为数据集合。其中用户行为是指：
(1) 主站列表页主列表--> 用户浏览；
(2) 主站详情页展现-->用户点击；
(3) 收藏、拨打电话、投递简历-->用户交互|效果。
目前全站行为数据规模明细数据日均2.5T。
2. 全站行为数据仓库构建原则
全站行为数据仓库建设中，逐步借鉴和沉淀的数据仓库构建原则如下：
(1) 底层业务的数据驱动为导向同时结合业务需求驱动。
(2) 便于数据分析。
a) 屏蔽底层复杂业务；
b) 简单、完整、集成的将数据暴露给分析层；
(3) 底层业务变动与上层需求变动对模型冲击最小化。
a) 业务系统变化削弱在操作数据层；
b) 结合自上而下的建设方法削弱需求变动对模型的影响；
c) 数据水平层次清晰化。
(4) 高内聚松耦合。
a) 主题之内数据高内聚；
b) 主题之间数据松耦合。
(5) 构建仓库基础数据层
3. 数据仓库架构分层思想
数据仓库构建过程中，采用的分层思想，各层的功能及建模方式和原则介绍如下。
(1) ODS层
功能：
建模方式及原则：
(2) DWD层
功能：
建模方式及原则
(3) APP层
功能：
建模方式及原则：
4. 模型实施过程
全站行为数据仓库建设过程，整体数据建设模型实施过程如下：
(1) 充分的业务调研和需求分析，决定后续数据仓库模型构建过程的正确性。
(2) 数据总体架构设计，构建统一、合理、清晰的数据仓库架构。
(3) 详细设计。抽象数据需求，保证数据需求&问题解决的完备性。
(4) 代码开发和测试。
(5) 数据DIFF。
a) 模型迭代-字段DIFF，对迭代过程中，模型中非迭代的每个字段的正确性做迭代前后DIFF，保证字段级数据质量；
b) 模型构建-指标DIFF，对模型构建中，模型中的业务数据指标进行DIFF，保证构建过程符合业务逻辑。
(6) 数据验收。从业务逻辑与模型构建方法过程保证数据模型落地的正确性。
a) 字段填充率；
b) 用户行为串联率；
c) 数据逻辑验证。
(7) 编写Wiki，构建统一的业务、数据知识体系，降低后续数据使用、维护成本。
(8) 数据上线；
a) 数据作业运维；
b) SLA质量保证。数据产出时效性、关键业务逻辑指标验证，保证数据可用性、稳定性。
5. 数据仓库建设规范
全站行为数据建设过程中，从表规范、编码规范来减低模型后续开发、维护成本。
(1) 表命名格式：[层次]_[主题][_表内容]_[分表规则]；
(2) 表命名格式：T_[层次]_[主题][_表内容]；
(3) 临时表命名格式：[tmp]_所属程序名_[自定义序号1…10]或[temp]_[操作者缩写]_YYYYMMDD_[表内容]；
(4) 视图命名格式：View_[表名]_[表内容]。
(1) 层次：ODS，DWD，APP；
(2) 表内容
(3) 分表规则
3、字段规范：
(1) 命名规范
a) 必须使用小写字母,并采用下划线分割；
b) 字段名禁止超过 32 个字符；
c) 字段名必须见名知意。命名与业务、产品线等相关联；
d) 字段名禁止使用 HIVE 保留字。
(2) 类型规范
a) 区分使用 TINYINT、SMALLINT、INT、BIGINT 数据类型,；建议使用 TINYINT 代替 BOOLEAN, 提高扩展性和类型转换兼容性；尽量使用低存储数据类型以提高运行效率；
b) 金额字段统一使用DECIMAL，时间字段(精确到十分秒)字段统一使用TIMESTAMP以提升比较效率， 分区字段及日期字段（没有时分秒）使用 String（格式统一为 yyyyMMdd）。
2) 编码规范
1、程序代码：每层一个代码目录，用于存放对应层的模型开发工程。
2、HQL代码：
(1) 使用 left semi join 代替 in/exists；
(2) join 时小表尽量放在左边，如小表足够小可使用 map join，hive 已支持自动判断大小表；
(3) 排序尽量使用 distribute+sort 组合，避免全表 order by；
(4) 尽量使用静态分区，提升运行效率；例行补数建议使用动态分区简化代码；
(5) 慎用笛卡尔积 join，卡历史数据建议使用日期维度表作笛卡尔积，以并行循环操作；
(6) 尽量使用窗口函数、udf 简化 sql 逻辑，提升代码可读性；
(7) join/group by/distinct 注意处理 NULL 值，尽量避免数据倾斜；
(8) union 会去重, 不用去重时使用 union all；
(9) 表查询如果是分区表, 尽量加上分区限制。
总结和展望
在全站行为数据建设过程中，
(1) 初步构建相对合理的数据体系结构，能够快速支持数据的集成，降低了业务迭代变化对数据模型的冲击；
(2) 业务知识体系初步建立，降低数据使用成本；
(3) 数据质量监控体系初步建立，能够对核心字段和数据指标进行监控，基本覆盖核心数据应用分析场景。
后续将围绕以下几点继续进行数据建设：
(1) 数据完整性：推进曝光数据覆盖范围，持续集成效果数据，提高全站行为数据内容丰富度；
(2) 数据质量：围绕数据产出稳定性与时效性，持续优化已有数据作业。
参考文献
1. 《大数据之路-阿里巴巴大数据实践》
2. 《数据挖掘：概念与技术》
作者简介
路亚州，58同城商业产品技术部工程团队高级大数据开发工程师
END
数仓社区
如有收获，请划至底部，点击“在看”，谢谢！